Information drives business. Companies today rely to an unprecedented extent on online, frequently accessed, constantly changing data to run their businesses. Unplanned events that inhibit the availability of this data can seriously damage business operations. Additionally, any permanent data loss, from natural disaster or any other source, will likely have serious negative consequences for the continued viability of a business. Therefore, when disaster strikes, companies must be prepared to eliminate or minimize data loss, and recover quickly with useable data.
Replication technology is primarily used for disaster recovery and data distribution. Periodic replication is one technique utilized to minimize data loss and improve the availability of data in which a point-in-time copy of data is replicated and stored at one or more remote sites or nodes. In the event of a site migration, failure of one or more physical disks storing data, or failure of a node or host data processing system associated with such a disk, the remote replicated data copy may be utilized. In addition to disaster recovery, the replicated data enables a number of other uses, such as, for example, data mining, reporting, testing, and the like. In this manner, the replicated data copy ensures data integrity and availability. Additionally, periodic replication technology is frequently coupled with other high-availability techniques, such as clustering, to provide an extremely robust data storage solution.
Performing a replication operation, backup operation, or the like on a large data set may take a significant amount of time to complete. The sheer size of the data set makes a replication operation take a significant amount of time. During this time, if the data set is maintained live, a problem with intervening accesses to the data set will have to be addressed. For example, on a large enterprise class system, there may be thousands of writes to that data set while it is being backed up or replicated. This factor can create data corruption hazards.
Currently, file system backup or replication (e.g., either incremental or whole file) requires knowledge of which all files changed in a file system. Further, it is required to know which regions of those files got changed for incremental backup. Replication or backup products either troll through the file system namespace looking for modified files which can be costly if a file system has tens of millions of files (e.g., a common case these days) and only a few thousand files get modified every day. The same holds true for new file creates and removed files. Using File Change Log (or analogous features) degrades file system performance significantly and requires agents to preserve the log before log wrap around.